Use RFC-compliant HeaderValue type. #287

PiotrSikora · 2024-10-28T22:12:38Z

When "header-value" feature is enabled, a RFC-compliant HeaderValue
type is used instead of the previously used UTF-8 String type.

Since HTTP field values aren't UTF-8 encoded, using the String type
meant that a plugin would crash when valid, but obsolete, non-UTF-8
characters were present in HTTP headers and/or trailers.

This feature is currently optional to avoid breaking changes and to
help with migration, but it will become a default feature in v0.3.

The HeaderValue type is re-exported from the http crate.

When "header-value" feature is enabled, a RFC-compliant HeaderValue type is used instead of the previously used UTF-8 String type. Since HTTP field values aren't UTF-8 encoded, using the String type meant that a plugin would crash when valid, but obsolete, non-UTF-8 characters were present in HTTP headers and/or trailers. This feature is currently optional to avoid breaking changes and to help with migration, but it will become a default feature in v0.3. The HeaderValue type is re-exported from the http crate. Signed-off-by: Piotr Sikora <code@piotrsikora.dev>

Signed-off-by: Piotr Sikora <code@piotrsikora.dev>

.github/workflows/rust.yml

PiotrSikora · 2024-10-29T17:53:27Z

src/hostcalls.rs

@@ -1159,46 +1193,59 @@ mod utils {
        bytes
    }

-    pub(super) fn serialize_map(map: Vec<(&str, &str)>) -> Bytes {
+    pub(super) fn serialize_map<V>(map: Vec<(&str, V)>) -> Bytes


Note to myself: drop Bytes if merged after #286.

PiotrSikora · 2024-10-29T18:34:46Z

README.md

+This crate supports the following optional features:
+
+- `header-value` - uses RFC-compliant `HeaderValue` instead of UTF-8 `String` for HTTP header and trailer values.
+  This will become the default in future releases.


Note that this PR doesn't introduce any changes or restrictions on header names in the SDK, since all valid HTTP field names are also valid UTF-8 strings, and proxies are very strict about this, so we never panic deserializing header names.

Having said that, I'm tempted to use HeaderName type while we're here, and turn this into a full typed variant.

Unfortunately, because we're passing HTTP/2 pseudo-headers (:authority, :status, etc.) in the header map, those names are non-compliant with RFC HTTP field names, so we'd need to either:

create wrapper around http::HeaderName type,

create our own more forgiving type,

return a pair of maps, one with pseudo-headers and one with HTTP headers.

It's unfortunate that http::HeaderName can't accomodate pseudo-headers, since that's a very common case. What does other Rust code do for handling H2 pseudo-headers, just use strings?

If there isn't any good external precedent, maybe (1), in the form of an enum type that can either be an http::HeaderName or a pseudo-header? Or would http::HeaderName plus a pseudoheader bool be sufficient to represent all cases?

It's unfortunate that http::HeaderName can't accomodate pseudo-headers, since that's a very common case. What does other Rust code do for handling H2 pseudo-headers, just use strings?

Pseudo-headers are a wire-format detail, and they are not intermixed with HTTP headers in any library or language that I'm aware of (other than Envoy), so that's not an issue that other people run into.

If there isn't any good external precedent, maybe (1), in the form of an enum type that can either be an http::HeaderName or a pseudo-header? Or would http::HeaderName plus a pseudoheader bool be sufficient to represent all cases?

http::HeaderName cannot contain : character, so a pseudoheader flag wouldn't work.

My other concern was that even if we "patch" http::HeaderName somehow, we still wouldn't be able to use http::HeaderMap that uses original http::HeaderName as long as pseudo-headers are intermixed with the regular HTTP headers.

I think we should separate them, at the very least at the SDK level, otherwise we're just propagating this Envoy-ism and making it hard-to-impossible to interoperate with the generic HTTP libraries available in various languages.

I'm sure this isn't helpful in Go SDK either.

PiotrSikora · 2024-11-03T13:31:23Z

Cargo.toml

 log = "0.4"

+[features]
+default = []
+header-value = ["dep:bytes", "dep:http"]


This feature could be renamed to valid-header, strict-header or rfc-header to make this reusable in case we want to add restrictions on header name in the future.

Alternatively, we could drop this as a feature and instead add those functions as variants with _typed() suffix.

Thoughts?

_typed() suffix would fit alongside the existing _bytes() suffix, so doesn't seem too bad to me.

No objection to keeping it as a feature, though, assuming we find a solution to the HTTP/2 pseudo-headers problem. If you keep it a feature, strict-header or rfc-header SGTM.

_typed() suffix would fit alongside the existing _bytes() suffix, so doesn't seem too bad to me.

Since the original version without suffix is fundamentally broken for the HTTP use case, I think we should drop it sooner rather than later, so I'll stick to the version from the existing revision of this PR and leave it without suffix behind a feature flag.

No objection to keeping it as a feature, though, assuming we find a solution to the HTTP/2 pseudo-headers problem.

Pseudo-header issue is orthogonal to this, since it only affects HTTP header names, and not values (this PR).

If you keep it a feature, strict-header or rfc-header SGTM.

My original thinking was that we need to have a flag for both: values only (this PR) and for both, so that we could add support for http::HeaderName and http::HeaderMap in a separate PR without making it a breaking change.

Having said that, I suspect that adding support for the latter is going to require splitting pseudo-headers and regular HTTP headers into separate maps, so it might be a much bigger change that'd be done as part of a bigger rewrite and not something simply hidden behind a feature flag.

Using http::HeaderValue is much more important, since the UTF-8 issue is causing panics and is pretty much broken.

Using http::HeaderName and http::HeaderMap only gives us better integration with existing Rust's HTTP ecosystem, but it doesn't really fix any issues, so it's a nice-to-have.

So strict-header-value (this PR) and strict-header (once we have support for both)?

PiotrSikora · 2024-11-03T13:40:47Z

src/hostcalls.rs

+    }
+
+    #[cfg(feature = "header-value")]
+    pub(super) fn deserialize_map(mut bytes: bytes::Bytes) -> Vec<(String, HeaderValue)> {


Note to self: drop bytes:: prefix if merged after #286.

Signed-off-by: Piotr Sikora <code@piotrsikora.dev>

PiotrSikora · 2025-06-05T18:22:47Z

@mpwarres could we get someone from Google to convert Rust tests in Envoy to use the header-value feature (it's already exposed via @proxy_wasm_rust_sdk//:proxy_wasm_header_value Bazel target), to verify that I didn't miss anything obvious, before we merge this PR? I converted some tests when I originally wrote this PR, which was a while ago, so the basics do work, but it wasn't a rewrite of everything.

PiotrSikora requested review from mpwarres and martijneken October 28, 2024 22:12

PiotrSikora marked this pull request as ready for review October 28, 2024 22:18

PiotrSikora mentioned this pull request Oct 28, 2024

robustness #271

Open

review: retain values from more forgiving hosts.

0542a78

Signed-off-by: Piotr Sikora <code@piotrsikora.dev>

PiotrSikora commented Nov 3, 2024

View reviewed changes

PiotrSikora requested a review from leonm1 January 3, 2025 15:50

PiotrSikora mentioned this pull request Mar 17, 2025

Differentiate between missing and empty headers. #305

Merged

PiotrSikora added 3 commits June 4, 2025 20:56

Merge remote-tracking branch 'origin/main' into PiotrSikora/header-value

3e9b789

Signed-off-by: Piotr Sikora <code@piotrsikora.dev>

Merge remote-tracking branch 'origin/main' into PiotrSikora/header-value

9bf47e6

Signed-off-by: Piotr Sikora <code@piotrsikora.dev>

Merge branch 'main' into header-value

17b8b75

PiotrSikora mentioned this pull request Jun 6, 2025

Add experimental "no-panic" feature. #319

Draft

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Use RFC-compliant HeaderValue type. #287

Use RFC-compliant HeaderValue type. #287

PiotrSikora commented Oct 28, 2024

Uh oh!

Uh oh!

PiotrSikora Oct 29, 2024

Uh oh!

PiotrSikora Oct 29, 2024

Uh oh!

mpwarres Apr 24, 2025

Uh oh!

PiotrSikora Jun 5, 2025

Uh oh!

PiotrSikora Nov 3, 2024

Uh oh!

mpwarres Apr 24, 2025

Uh oh!

PiotrSikora Jun 5, 2025

Uh oh!

PiotrSikora Nov 3, 2024

Uh oh!

PiotrSikora commented Jun 5, 2025

Uh oh!

Uh oh!

Use RFC-compliant HeaderValue type. #287

Are you sure you want to change the base?

Use RFC-compliant HeaderValue type. #287

Conversation

PiotrSikora commented Oct 28, 2024

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

PiotrSikora commented Jun 5, 2025

Uh oh!

Uh oh!